Read only when the channel does not auto-read - #2302

## Problem

For the default handler (`executeRequest(request)` ->
`AsyncCompletionHandlerBase`
-> `Response`) the body is copied three times:

1. `HttpHandler.handleChunk` -> `EagerResponseBodyPart` copies each
chunk out of
the network buffer into a heap `byte[]` (needed: `channelRead` releases
the
   message afterwards);
2. `NettyResponse.getResponseBodyAsByteBuffer` concatenates every part
into a
   freshly allocated array;
3. `getResponseBody(charset)` decodes that array.

Step 2 is pure waste when there is only one part, which is the case for
any body
that lands in a single socket read: it copies a single part into a new
array with
nothing to concatenate it with.

## Change

`getResponseBody(Charset)` decodes straight from the part when there is
exactly
one of them. The array does not escape the method, so the part's own
array can be
decoded in place.

Several parts are still concatenated before decoding, never decoded one
at a
time, because a multi-byte character can straddle a part boundary.

`getResponseBodyAsBytes` and `getResponseBodyAsByteBuffer` are
deliberately left
untouched: they hand the array to the caller, so they keep making a
defensive
copy rather than expose a part's own array. There is no aliasing change
anywhere
in this PR.

## Measurements

Rough probe on JDK 17 over a single-part ASCII body,
concatenate-then-decode
versus decode-in-place. Not JMH, so read the shape rather than the
digits:

| body | before | after |
|------|--------|-------|
| 512 B | 496 ns | 47 ns |
| 4 KB | 2277 ns | 373 ns |
| 16 KB | 2963 ns | 1450 ns |
| 128 KB | 24913 ns | 12248 ns |

Plus one fewer whole-body allocation per response. The percentages look
large
partly because a pure-ASCII body decodes through a JDK intrinsic, which
makes the
removed copy a big share of what is left.

## Tests

Two added to `NettyAsyncResponseTest`:

* `testGetResponseBodyDecodesOnePartAndSplitPartsIdentically` splits the
two-byte
UTF-8 encoding of U+00E9 across two parts and asserts one-part and
split-part
bodies decode alike. This pins the constraint the comment states: it
fails if
  anyone later makes the multi-part path decode part by part.
* `testGetResponseBodyAsBytesDoesNotShareTheBodyPartArray` pins that
`getResponseBodyAsBytes` still returns a fresh array and never the
part's own.

The body bytes are built as an explicit `byte[]` rather than a string
literal to
keep the source ASCII per `AGENTS.md`.

## Verification

`mvnw clean verify` - BUILD SUCCESS, 1373 tests (1371 before, plus these
two),
0 failures, 0 errors, 19 skipped. Error Prone, NullAway and Revapi
clean.
`LargeResponseTest`, `NoNullResponseTest`,
`BodyDeferringAsyncHandlerTest` and
`RedirectBodyTest`, which exercise the multi-part path, are green.

Caveat on the testing gate: `AGENTS.md` requires the build to run on JDK
11 and
no JDK 11 is installed on this machine, so it was run on **JDK 17**
(also in the
CI matrix). The JDK 11 leg of CI on this PR is the real gate.

## Not in scope

The multi-part case still concatenates. A
`CompositeByteBuf.toString(charset)`
variant measured faster there (Netty decodes a multi-component buffer
through a
recycled, un-zeroed thread-local array instead of a fresh `byte[]`), but
it
regressed at high part counts in the same probe, so it needs proper
benchmarking
before it becomes a change. Removing copy 1 would mean retaining network
buffers
and giving `Response` a lifecycle, which is public API and wants a
design
discussion first.

No public API change here. Same review pass as #2300, #2301 and #2302.

Claude Code on behalf of @pavel-ptashyts

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Aayush Atharva <24762260+hyperxpro@users.noreply.github.com>

Motivation:

#2302 stopped AsyncHttpClientHandler requesting a read that Netty's
HeadContext already drives when autoRead is on.
Nothing in the suite catches that duplicate coming back, since the
connection works correctly either way

Modification:

Add AsyncHttpClientHandlerReadTest, an EmbeddedChannel test that counts
reads at an outbound handler placed in front of the handler under test,
so it sees both entry points.
Covers channelActive and channelReadComplete with autoRead on, and
channelReadComplete with it off.

Result:

One read per cycle with autoRead on, reads still driven with it off;
without #2302 the count is 2.